The problem of passing not serialized requests to engine is that the spec misses a part of the protocol, particularly, EL can only use SSZ serialized requests for the commitment validation. SSZ encoding in this case is not an engine API artefact, it would be necessary even if CL and EL had direct communications and were a part of the same process/binary

yeah this PR and the execution-apis one I linked above pair together, and to me are a better expression of what we are trying to accomplish

putting SSZ serialization into the state transition function is a violation of the (sub)layers of the protocol, and also complicate testing (as now the correctness of the state transition function depend directly on SSZ serialization in a way that they didn't really before)

as now the correctness of the state transition function depend directly on SSZ serialization in a way that they didn't really before

I see, but they do really depend now as the requests commitment computation uses SSZ under the hood. Alternatively, we can write a custom decoder in the CL for this particular case and not call it SSZ in the spec